1. Technical Field
The present invention relates in general to system message transmission and in particular to message queuing in a data processing system. Still more particularly, the present invention relates to a system, method and computer program product for implementing shadow queues for recovery of messages.
2. Description of the Related Art
In distributed computing environments, the performance of tasks is driven by the routing of incoming messages into and out of a queue. The handling of queues for performance frequently damages queue reliability by removing data prematurely. An example of a system driven by incoming events is present in the Java 2 Enterprise Edition (J2EE).
In such a system, particularly for enterprise applications, a messaging queue is present, which contains a table of addresses of messages in a message store and routes messages to components at an appropriate time based on queuing rules. Components “listen to the queue” by receiving and processing incoming messages. Users of Java 2 Enterprise Edition refer to this mechanism as the java messaging service (JMS).
In some systems, queuing behavior is specified by programming constructs. In Java 2 Enterprise Edition, a message-driven bean (MDB) is a construct that specifies the queuing behavior of messages. Users of such message constructs implement an “onMessage” component to the message, in which the programmer deals specifically with the content of the incoming message while the underlying MDB infrastructure handles the system details, such as message queueing and routing, and communication details, such as Domain Name Server behavior, in a user-transparent fashion.
Specifically, incoming messages in a Java 2 Enterprise Edition environment are received and stored onto a message database. The lifetime of a message stored in the message database is equivalent to the receiving MDB's transaction lifetime (i.e. until the next asynchronous hop). However the lifetime of a J2EE application transaction can exceed an MDB's transaction lifetime, thus requiring the availability of actual messages beyond the J2EE transaction lifetime. Recovery purposes represent a common use of message stores and therefore consume a significant portion of system resources.
Systems such as those described above are designed to provide transactional support. As a result, if there are multiple tasks within a transaction, they typically exhibit “all or nothing” behavior. If any of them fails, then all are classified as having failed together. The “all or nothing” behavior is provided by the fact that, at the end of any transaction, the system will check all internal tasks within the transaction. If any component transaction fails, then all component transactions are rolled back to their original state.
Normally, transactions end upon a shift to another queue or another thread, when the originating MDB completes its invocation and arrives at the back end of the transaction, ending the transaction. Subsequently, as a part of a message database cleanup, the message is cleaned from the queue. However, if the application is an event-driven system with multiple asynchronous hops, such behavior will lead to premature message deletion before all the asynchronous hops are completed, a state which hinders features such as failure recovery.
The prior art method used to circumvent such problems is to store the incoming message in a separate persistent store (a database or a persistent queue) which is associated with an application's transaction lifetime as opposed to a J2EE component's transaction lifetime. This method excessively consumes system resources and inhibits performance. A solution is needed that addresses the resource consumption problems associated with the prior art. What is needed is a system, method and computer program product for implementing shadow queues for recovery of messages.